… regressions

The repository's GitHub Actions workflow had been failing for some time due
to a combination of Bazel version drift (last_rc -> 9.1.1rc1), breaking
changes in Bazel's glob and sh_test defaults, and regressions in the rule
implementations and test data.

Infrastructure (Bazel 8.4.2 + stricter glob/sh_test defaults):
- .bazelversion: last_rc -> 8.4.2
- erlang_app.bzl: allow_empty=True on 9 native.glob sites (include/, etc.)
- ct.bzl: allow_empty=True on the 2 globs in ct_suite/ct_suite_variant
- test/MODULE.bazel: platforms 0.0.7 -> 0.0.11; add rules_shell 0.6.1
- test/app_file/BUILD.bazel: switch app_file to public load; load sh_test
  from @rules_shell (no longer in @bazel_tools by default)

CT/eunit regressions introduced in 228b062 "Fix testing support (ct, eunit)":
- private/ct.bzl: flat_deps(deps + compiled_suites) -> flat_deps(deps);
  compiled_suites are .beam files, not ErlangAppInfo providers, so passing
  them through flat_deps causes an analysis-time error
- private/ct.bzl: ct_run -dir ebin -> -dir test; the ct_suite macro still
  compiles SUITEs to dest="test", so -dir ebin found no suites

Test data updates for product changes:
- test/shard_suite/BUILD.bazel: erlang_bytecode2 -> erlang_bytecode v1
  (v1 accepts string-list erlc_opts); replace eunit(compiled_suites=...)
  (no such attr) with test_beam=[...] on test_erlang_app + eunit_mods
- test/rules_erlang_compiler/test/dot_app_file_SUITE.erl: add
  test_modules => [] to the Target map (228b062 made the key mandatory
  in dot_app_file:render/3 but did not update the test)

Product bug fix:
- tools/rebar_config_to_erlc_opts/src/rebar_config_to_erlc_opts.erl:
  honor no_debug_info in rebar.config erl_opts by dropping the default
  +debug_info from the output when no_debug_info is present; also
  lists:flatten the io_lib:format result so output entries are flat
  strings rather than nested iolists like [[43],"deterministic"]

Local result with Bazel 8.4.2: 13/13 tests pass in test/.

Three independent fixes that were preventing the bzlmod test jobs from
passing under Bazel 8.4.2:

1. private/ct.bzl: code_paths

   The helper was joining `dep.label.workspace_root` with short
   dirnames that already start with `../<canonical_repo_name>/`. In a
   bzlmod runfiles tree there is no `external/` directory at all, so
   the resulting path `external/rules_erlang+/../rules_erlang+/...`
   does not exist and dialyzer fails with "No such file, directory or
   application". Short paths already contain the correct runfiles
   prefix for files from other repositories, so the workspace_root
   should not be prepended.

   Affects //erl_attrs_to_json:dialyze,
   //rebar_config_to_erlc_opts:dialyze, //rules_erlang_compiler:dialyze.

2. tools/rules_erlang_compiler/src/types.hrl

   Commit 228b062 ("Fix testing support (ct, eunit)") made
   dot_app_file:render/3 destructure `test_modules` out of the target
   map but never updated the `target()` (and `target_extended()`)
   typespec, causing a dialyzer "Invalid type specification" error.

3. MODULE.bazel + repositories/erlang_config.bzl

   Since bfb48d7 ("Revert "Revert "default to internal"") the default
   value of the `erlang_internal_external` constraint setting is
   `erlang_internal`. That works for test/MODULE.bazel which uses
   internal_erlang_from_github_release, but the root MODULE.bazel
   uses external_erlang_from_path (auto-detected via _default_erlang_dict),
   so the host platform no longer satisfies the toolchain's
   `exec_compatible_with = ["//:erlang_external"]` requirement and
   resolution fails with "No matching toolchains found for types:
   //tools:toolchain_type" in unit-test-bzlmod.

   Generate an `erlang_external_platform` (parented on @platforms//host)
   in the @erlang_config repo and register it from the root MODULE.bazel
   via register_execution_platforms. This makes the external toolchain
   resolvable at the root without changing the new "default to internal"
   semantics that the test/ jobs rely on.

- Bump DEFAULT_ERLANG_VERSION from 26.0 to 28.1 (with updated sha256).
  OTP 26.0 source builds fail on the newer macOS 15 runner image, and
  pinning ancient releases for everyone is undesirable. 28.1 is the
  current stable release and builds cleanly on Linux and macOS.

- test-bzlmod-macos: pin runs-on to macos-15 (was macos-latest, which
  has moved to macos-26 / Tahoe). macos-15 / Sequoia is the conservative,
  well-tested image; revisit once macos-26 has had more bake time.

- test-bzlmod-windows: pin runs-on to windows-2025 (was windows-latest,
  whose new image is not yet recognised by erlef/setup-beam), and bump
  the matrix OTP to 28.1 to match the new default.

- Drop test-host-erlang-change-detected entirely. The job depends on the
  :otp_version target and the erl_eval.bzl rule, both of which were
  removed in dc6c4b7 ("Remove unused rules, tools, and examples"). The
  job is also removed from the summary needs list.

test-bzlmod-internal-erlang is left alone: it relies on a BuildBuddy
API key that's available in repository secrets.

…N bump

After bumping DEFAULT_ERLANG_VERSION to 28.1, two test/ artifacts still
referenced the old major version and broke analysis / runtime:

- test/BUILD.bazel + test/.bazelrc: rename the `erlang_26_platform`
  alias (and the rbe --platforms flag pointing at it) to
  `erlang_28_platform`. `@erlang_config//:erlang_<major>_platform`
  targets are only generated for the OTP majors that are actually
  registered, so with the default internal Erlang now at 28.1 the
  alias' `actual` did not exist and `bazelisk test //...` failed
  during analysis for every job.

- test/custom_vars/custom_var_test.sh: the test was checking that the
  OTP_VERSION toolchain variable matched `2[4-6]\.`, which only ever
  served to confirm the variable was populated. Relax the regex to
  `[0-9]+\.[0-9]+` so it accepts any modern OTP major (now exercising
  25.3, 26.2, 28.1 and the host OTP on macOS).

Validated with `cd test && bazelisk test //...`: all 13 tests pass.

The windows-2025 runner image reports ImageOS=win25-vs2026, which
erlef/setup-beam@v1 does not recognise. The action's supported set
includes the bare 'win25', so pass it explicitly via the step's env.

unit-test-bzlmod ran 'bazelisk test //...' at the repo root, but the
root has no test targets (all live in test/, covered by the test-bzlmod
job). Bazel exits non-zero with 'No test targets were found, yet
testing was requested'. The job's purpose is to verify the root
MODULE.bazel resolves and builds, so 'build' is the correct verb.

Also bump the root bazel_dep on platforms from 0.0.10 to 0.0.11 to
match test/MODULE.bazel and silence the --check_direct_dependencies
warning during analysis.

test-bzlmod-windows referenced --@rules_erlang//:ct_test_windows_logdir_drive_letter,
which was deliberately removed (along with all other Windows-specific
code paths) in 413df65 "drop windows". The job cannot be made to pass
without reverting that decision, so remove it from the workflow and
from the summary.needs list.

test-bzlmod-internal-erlang was hitting BuildBuddy's anonymous-access
deprecation (FAILED_PRECONDITION). Wire the BUILDBUDDY_API_KEY secret
into the CONFIGURE BAZEL step and append --remote_header to the
buildbuddy bazelrc config so authenticated traffic is used.

The 'secrets' context is not allowed in job-level 'if:' (only github,
needs, vars, inputs are). The previous attempt produced a workflow
syntax error that aborted the entire Test run. Replace the inline
secrets check with a tiny check-buildbuddy-secret job that exports
'has-key' as a job output, then gate test-bzlmod-internal-erlang on
'needs.check-buildbuddy-secret.outputs.has-key == true'.

Examples workflow was stuck queued forever because ubuntu-20.04 was
retired from GitHub-hosted runners. Bump to ubuntu-24.04 to match the
rest of the workflows.

examples/basic was deleted in dc6c4b7 'Remove unused rules, tools, and
examples'. The surviving example is examples/umbrella, which has eunit
and ct_test targets. Update the workflow path, job name, and artifact
name accordingly.

Previously every extract_app target in a package declared its outputs
under <package>/ebin/<file>. That made it impossible to have two
extract_app targets (e.g. a prod :erlang_app and a :test_erlang_app)
in the same package, because both would race to declare the same
ebin/<file>.{beam,app} outputs and Bazel would reject the analysis
with a duplicate-action error.

Namespace only the .beam and .app outputs under <target_name>/ebin/.
The header and priv outputs are left at their natural location: the
package-prefix-stripping helper additional_file_dest_relative_path()
in private/util.bzl expects them there, and shifting them would
double the package segment when those files are later placed into a
runtime erl_libs tree (which manifested as relx failing to find its
priv/templates/* at release-assembly time).

DEFAULT_PLT_APPS only covers erts/kernel/stdlib. The umbrella's
:test_erlang_app targets pull in test sources (greeter_tests.erl,
greeter_web_tests.erl) that call eunit:test/1, so dialyzer reports
'Unknown functions: eunit:test/1' and exits with warnings. Extend
each app's plt() apps list with eunit and common_test so the
analysis can resolve test-framework calls.

By default GitHub propagates 'skipped' through job dependencies, so the
summary job was being auto-skipped whenever test-bzlmod-internal-erlang
is skipped on forks/branches without BUILDBUDDY_API_KEY. That defeats
the summary's gating role.

Add 'if: ${{ !cancelled() }}' so the summary runs on success / failure
/ skipped (but not on cancellation), letting the existing jq check
('success' or 'skipped') decide pass/fail.